En 2017, cuando Cloudflare lanzó Workers, la propuesta era casi una curiosidad: ejecutar pequeños trozos de JavaScript en los mismos nodos que servían los CDN, con latencia mínima y sin gestionar servidores. Ocho años después, esa curiosidad se ha transformado en una plataforma de aplicaciones con base de datos, almacenamiento de objetos, colas, pub/sub, inferencia de IA y catálogo de integraciones empresarial. La pregunta ya no es «¿para qué sirve esto?», sino «¿dónde encaja en mi arquitectura?». Y esa pregunta merece una respuesta matizada.
Qué ofrece hoy
La arquitectura básica no ha cambiado: cada Worker es una función que corre en V8 isolates, se despliega globalmente en segundos, arranca en frío en menos de 5 ms, y se factura por petición y por milisegundos de CPU. Esto sigue siendo el corazón del producto y es la razón por la que Workers gana a Lambda en todos los casos donde la latencia del cold start importa.
Lo que ha cambiado es todo lo que rodea al Worker. D1 (SQLite distribuido, con replicación regional) ha salido de beta y es usable en producción para cargas moderadas. R2 (almacenamiento compatible con S3 sin tarifas de egreso) ha desplazado a S3 en muchos despliegues donde el tráfico de salida pesa más que el almacenamiento. Durable Objects, la primitiva más rara del catálogo, es hoy la base sobre la que se construyen ediciones colaborativas, salas de chat y coordinadores de estado distribuido sin servidor explícito. Queues, Pub/Sub y Workflows completan el puzzle para arquitecturas orientadas a eventos.
Workers AI es la incorporación más reciente y probablemente la más relevante comercialmente. Permite ejecutar una selección amplia de modelos abiertos (Llama, Mistral, Stable Diffusion, modelos de embeddings) directamente desde un Worker, sin gestionar infraestructura GPU. La latencia es razonable y el modelo de precios por tokens es más predecible que el de los proveedores que factura por GPU-hora.
Dónde encaja bien
El caso estrella sigue siendo cualquier carga donde «cerca del usuario» importa. API gateways, lógica de personalización, A/B testing en el borde, reescritura de cabeceras, protección contra bots específica por ruta: Workers es casi imbatible aquí. La latencia desde cualquier punto del planeta a un Worker cercano es de decenas de milisegundos, y la facturación por uso real evita el problema clásico de tener servidores ociosos en regiones secundarias.
El segundo caso donde destaca es aplicaciones completas que encajan en el presupuesto de CPU y memoria de un Worker (128 MB, tiempo de CPU configurable hasta 5 minutos en planes de pago). Para SaaS de tamaño pequeño o mediano, con D1 como base de datos y R2 como almacenamiento, puedes cubrir prácticamente todo el stack sin tocar otra infraestructura. Muchos productos de nicho se están lanzando así.
El tercer caso, que ha crecido mucho durante el último año, es ejecutar pipelines de IA sencillos. Un Worker recibe una petición, llama a Workers AI para generar embeddings o completar un prompt, consulta Vectorize (la base vectorial de Cloudflare) y devuelve el resultado. Todo el pipeline vive en la red de Cloudflare, sin egreso. Para sistemas RAG ligeros, esta topología es difícil de batir en coste y simplicidad.
Dónde sigue sin encajar
Pese al crecimiento del catálogo, hay casos donde Workers no es la opción correcta, y conviene saberlos de antemano.
Cargas con estado grande en memoria (más de 128 MB) no caben. Podés dividirlas entre varios Workers o apoyarte en Durable Objects, pero cualquiera que necesite un proceso grande y persistente va a sufrir.
Bibliotecas de lenguajes distintos a JavaScript/TypeScript siguen teniendo limitaciones. El runtime soporta Rust y Python a través de WASM y Pyodide respectivamente, pero el ecosistema de librerías disponibles es reducido. Si tu aplicación depende fuertemente de paquetes específicos de Python científico o de C++ compilado, Workers no es tu sitio.
Bases de datos relacionales con requisitos altos de consistencia global también son delicadas. D1 funciona bien para aplicaciones de tamaño medio, pero la consistencia eventual en otras regiones significa que no es reemplazo directo de un Postgres multi-región con replicación síncrona. Para cargas de banca o similares, habrá que buscar otra opción.
Los precios y la letra pequeña
Cloudflare ha estado ajustando su modelo de precios durante el último año, y hay matices que conviene mirar. El plan gratuito sigue siendo generoso para experimentar. Los planes de pago (Workers Paid, Workers Unbound, ahora unificados) facturan por peticiones y por CPU usado, con mínimos razonables.
Donde hay que prestar atención es a las características «avanzadas» con precios separados: Workers AI factura por tokens o inferencias, R2 cobra por operaciones aunque no haya egreso, y D1 cobra por filas leídas/escritas. Todo razonable en sí, pero hay que hacer cuentas en lugar de asumir una tarifa única.
El otro cambio interesante es la llegada del plan Enterprise con acuerdos y soporte dedicado, y la integración con mercados corporativos (AWS Marketplace, Azure). Esto es señal clara de que Cloudflare está entrando en conversaciones que antes no tenía acceso.
Cómo pensar la decisión
La pregunta útil a la hora de valorar Workers no es «¿es mejor que Lambda?» sino «¿cuánto peso ocupa la lógica en el borde en mi arquitectura?». Si la respuesta es mucha (API públicas con mucho tráfico, lógica de autenticación, rutas específicas por región, APIs con mucho caché), Workers gana por un margen cómodo. Si la respuesta es poca (aplicaciones con procesamiento pesado en backend central y poca lógica de frontera), el coste operativo de dividir tu arquitectura entre dos plataformas probablemente no compensa.
La ruta incremental que me parece más sensata, y que he visto funcionar, es empezar con un único Worker delante de tu stack actual, para manejar autenticación ligera, cache o rewrites. A partir de ahí, ir moviendo piezas al borde conforme tenga sentido técnico y económico. Evita rediseñar todo desde cero en Workers: la plataforma es potente, pero su modelo mental es distinto del de un servidor tradicional, y asumirlo de golpe suele terminar en fricciones que se pueden evitar.
Lo que viene
Lo que Cloudflare señaló en su último Birthday Week sugiere que el foco para 2025 es dos cosas: profundizar Workers AI (más modelos, precios mejores, latencia reducida) y empujar Durable Objects como primitiva fundamental para stateful apps. Si ambas apuestas salen bien, Workers se convertirá en una plataforma que compite de frente con Lambda+DynamoDB para cualquier carga que no exija procesamiento masivo centralizado.
Ocho años después de su debut discreto, Workers ha dejado de ser una herramienta de nicho. Sigue siendo la opción más elegante para lógica de borde, y se ha ganado el derecho a entrar en la lista corta para aplicaciones completas. Es de las pocas plataformas donde la innovación técnica y el modelo de negocio han evolucionado de forma coherente, y eso explica por qué los equipos que prueban Workers rara vez vuelven atrás.
